Method and system for communicating between an embedded device and relational databases

ABSTRACT

Techniques for communicating between an embedded device and at least one remote database for a wide variety of applications, including human machine interface and supervisory control and data acquisition and B2B applications. An application program interface interfaces an application program seeking access to a predetermined database and which operates on an operating system not operating a database driver program. A parser translates communications with the application program interface into and from commands and formatted data of an operating system independent form. A protocol stack formats the commands and formatted data into header formatted communications signals to accord with a predetermined protocol. Another protocol stack receives the header formatted communications signals and removes header data from the header formatted communications signals for generating database communications signals. Another parser receives the database communications signals, generates a plurality of database formatted SQL commands, and communicates the database formatted SQL commands. A database interface interfaces the predetermined database and communicates the database formatted SQL commands with the predetermined database.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of copending U.S. patent applicationSer. No. 11/243,780 which is hereby incorporated by reference as if setforth fully herein. Application Ser. No. 11/243,780 claims priority toU.S. Provisional Patent Application Ser. No. 60/646,041 which is alsohereby incorporated by reference as if set forth fully herein.

FIELD

The disclosed subject matter relates to data communications withinnetworked computer systems and related software. More particularly, thisdisclosure relates to a novel and improved method and system forcommunicating between an embedded device and at least one of potentiallymany relational databases.

DESCRIPTION OF THE RELATED ART

In many industries there is the need for software products that permitdeveloping and using Windows®-based applications in industrialautomation, instrumentation and embedded systems. Such systems empowerworkers and companies to develop graphical interfaces, integrate webbrowsers, and take advantage of Internet connectivity. Some of the moreattractive applications use the Internet to access data that is storedon industrial devices and test and measurement equipment. In addition,such tools and technologies convert personal computers, web browsers,and remote productivity devices such as cell phones, pagers, andpersonal digital assistants (PDAs) into industrial automation and testand measurement systems.

As technologies emerge for acquiring data in real time from a variety ofreal-world devices and displays, and accesses real-time, dynamic, andanimated graphic screens, trends, recipes, and reports on the mostpopular web browsers, imports and exports data in XML format for easyintegration with corporate and business applications there is the needto integrate seamlessly with databases and the Microsoft® Office Suite®and similar application programs. Such systems must provide a strongarchitecture that encompasses the latest standards and technology in thewireless, mobile, distributed, and Internet areas.

One particularly important area of software development is known asRapid Application Development Environment. These applications alloworganizations to increase productivity and establish predictive andpreventative maintenance strategies that result in optimum processuptime and availability. In such uses, there is often the need to accessdatabases that may store and provide to the application information foruse in a real-time environment.

In the traditional approaches, in order to utilize Object LinkingEmbedded-Database® (OLE-DB® and Open Database Connectivity® (ODBC®), orActiveX Data Objects® (ADO®) to interface to local or remotedatabase(s), the HMI/SCADA device must have an ODBC driver and/or ADO®provider developed for and running on the operating system supportingthe Rapid Application Development software. For devices based on theMicrosoft® Windows® CE®, Linux® or other embedded devices, these ODBC®drivers or ADO® providers may not exist.

Accordingly, a need exists for a method and system for Rapid ApplicationDevelopment software to read and write real-time machine or process datato any local or remote database, including, for example, a SQLrelational database, without the need for database driver interfaces tobe supported on the operating system supporting the application.

SUMMARY

Techniques for providing novel and improved methods and systems forcommunicating between an apparatus and at least one relational databaseare disclosed, which techniques improve both the operation of industrialdevice software applications and promote the efficient use of dataresiding and storable in a variety of relational databases and the like.The disclosed subject matter, therefore, enhances the use of real-time,dynamic, applications reporting alarms, trends, recipes, and reports ofindustrial devices to provide a strong architecture that encompasses thelatest standards and technology in the wireless, mobile, distributed,and Internet areas.

According to one aspect of the disclosed subject matter, techniques forcommunicating between an industrial apparatus and at least one remotedatabase include a database communications system that uses a databasecommunications gateway between a plurality of applications and apredetermined database. The database communications gateway includes anapplication program interface for interfacing at least one applicationprogram which may seek to access a predetermined database and whichapplication program operates on an operating system not operating adatabase driver program. A first parser translates communications withthe application program interface into commands and formatted data,which commands and formatted data are in an operating system independentform. A first protocol stack formats the commands and formatted datainto header formatted communications signals which accord with apredetermined protocol and communicates the header formattedcommunications signals. A second protocol stack receives the headerformatted communications signals and removes header data from the headerformatted communications signals for generating database communicationssignals. A second parser receives the database communications signals,generates from the database communications a plurality ofdatabase-formatted communications signals, and communicates thedatabase-formatted communications signals to a database interface. Thedatabase interface interfaces the predetermined database andcommunicates the database-formatted communications signals with thepredetermined database.

These and other advantages of the disclosed subject matter, as well asadditional novel features, will be apparent from the descriptionprovided herein. The intent of this summary is not to be a comprehensivedescription of the claimed subject matter, but rather to provide a shortoverview of some of the subject matter's functionality. Other systems,methods, features and advantages here provided will become apparent toone with skill in the art upon examination of the following FIGUREs anddetailed description. It is intended that all such additional systems,methods, features and advantages be included within this description, bewithin the scope of the accompanying claims.

BRIEF DESCRIPTIONS OF THE DRAWINGS

The features, nature, and advantages of the disclosed subject matterwill become more apparent from the detailed description set forth belowwhen taken in conjunction with the drawings in which like referencecharacters identify correspondingly throughout and wherein:

FIG. 1 depicts an exemplary industrial environment in which theteachings of the disclosed subject matter may provide particularadvantages and numerous benefits;

FIG. 2 is a simplified block diagram of a data base communicationssystem that may implement the present embodiment;

FIG. 3 illustrates an software architecture diagram for the embodimentof FIG. 2;

FIGS. 4 and 5 show an exemplary application that may form an integralpart of the present embodiment;

FIG. 6 shows functional aspects of the gateway process and system of oneembodiment of the disclosed subject matter;

FIG. 7 presents an exemplary client-server environment in which topractice aspects of the present disclosure;

FIG. 8 depicts functional aspects of a relational database that may beaccessed using an embodiment of the disclosed subject matter; and

FIG. 9 further portrays an application of the disclosed subject matterenabling access to and communications with a plurality of databasesoperating under a variety of protocols.

DETAILED DESCRIPTION OF THE SPECIFIC EMBODIMENTS

The disclosed subject matter for providing novel and improved methodsand systems for communicating between an industrial apparatus and atleast one relational database has use in an essentially unlimited numberof industrial, clinical, embedded, and other manufacturing, serviceproviding, and process control environments requiring rapid applicationdevelopment applications with strong relational database integration.One such application appears in FIG. 1, which portrays oil field 10wherein a drilling application employs drill bit 12 for boring a hole toexplore and produce oil. As inset 14 shows, a drill bit may bore throughvarious layers of earth. A user of an electronic device, such as aWeb-enabled PDA, cell phone or other device may desire, and, throughusing the subject matter here disclosed, be empowered to receive manytypes of information relating to oil-field operations and supportingoptimal management on and production from oil field 10.

As inset 16 shows, for example, the user may receive informationrelating to drilling operations, refining operations, extractingoperations, and the like, as well as receive documents and streamingtutorials of relevance and beneficial to oil field 10 production. Asinset 18 shows, the same user may use various operational and Internetaccess controls, as well as control user information and groupinformation using such a device. Furthermore, inset 20 depicts theaspect of the present disclosure that may relate to the monitoring ofequipment in and around the various sites of oil field 10. Many of theseapplications may use third party software applications. Many suchapplications may also provide stand-alone operation, not requiringdatabase access. However, for applications capable of making effectiveuse of SQL relational databases, for example, the present disclosureprovides major improvements in the operations of oil field 10 andcontrol of devices and systems therein. Such improvements, it should beclear, have application in a great many industrial environments for theimproved operations and controls of a wide variety of industrialequipment and devices and systems for such equipment and devices.

FIG. 2 is a simplified diagram of database communications system 30 thatmay implement the teachings of the present disclosure. In particular,FIG. 2 portrays the concept that database communications system 30 mayprovide for use of application software at application site 32.Application site 32, which may use any one of a variety of applications,interfaces and communicates with database gateway site 34 via, forexample, a TCP/IP connection 36. As such, database gateway site 34 maybe a location remote from application software site 32. Database gatewaysite 34 includes software that associates with a database provider andprovides access path 38 to communicate with one of a variety of databasefiles at database file site 40.

Database communications system 30 may used, for example, in conjunctionwith the InduSoft® Web Studio®, described in further detail below, atapplication site 32 to provide for database file 40 access for a varietyof human-machine interface (HMI) and supervisory control and dataacquisition (SCADA) applications. HMI applications provide a variety ofinterface functions with human operators and the machines they maycontrol. SCADA applications, on the other hand, monitor and controllarge manufacturing machinery or processes. Database communicationssystem 30 provides a means for using these classes of devices onoperating systems such as Microsoft® Windows® CE®, Linux®, or otherembedded operating systems and, most importantly, interface valuabledata and commands that may operate on remote SQL (Structured QueryLanguage) relational and other similar databases. Databasecommunications system 30 implements a generic connection enablingHMI/SCADA applications to route the requested remote database operationto a desktop computer, running Windows® XP®, or Windows® 2000®, whichuse ADO.NET® to provide an intuitive, simple, flexible and powerfulinterface with any database compatible with MDAC® (Microsoft Data AccessComponents), using underlying technologies such as OLE-DB® and ODBC®.

FIG. 3 illustrates a software architectural diagram 50 for oneembodiment of database communications system 30 of FIG. 2. Distinctsoftware applications associated in the present architecture, which mayinclude HMI/SCADA software or other data rich applications 52,communicate with database gateway software 54 via TCP/IP or UDP/IPprotocol software 56. Database gateway software 54 connects twodifferent software applications, 52 and SQL relational database drivers,which use different protocols for storing or interpreting data. RapidApplication Development software 52 exchanges data with the databasegateway software 54 using TCP/IP or UDP/IP software 56 over any physicallayer supported by these protocols. Therefore, Rapid ApplicationDevelopment software 52 and database gateway software 54 may run on thesame platform or on different platforms. By this way, even if theapplication site 32 on which Rapid Application Development software 52operates does not support the ADO®, OLE-DB® or ODBC® interfaces, RapidApplication Development software 52 may exchange data with remotedatabase software 60 through the database gateway software 54, which mayoperate at database gateway site 34.

In operation, database gateway software 54 communicates with one or moreof a variety of driver software systems 62, such as ODBC® softwaredrivers, ADO® providers, and/or OLE-DB® providers for access via path 58to SQL relational database software 60. A SQL relational database atdatabase file site 40 uses a structured query language, which is across-platform language permitting the user to select, update, insert ordelete data in a relational database. ODBC® software drivers provide anapplications programming interface interfaces to databases such asMicrosoft SQL Server®, Oracle®, and Microsoft® ODBC® desktop databasedrivers, which support Microsoft® Access®, Excel®, and dBase®. ODBC® istypically used with tools such as DAO® or ADO®. ADO® provides aMicrosoft® technology used by developers to connect applications todatabases.

FIG. 4 shows user interface 70 from an exemplary application 72 that mayoperate at application site 32. Such an application may be the InduSoft®Web Studio®, which may operate at application site 32 to provide apowerful, integrated collection of automation tools for developinggraphical real-time applications operable to run native on Windows® NT®,2000®, XP®, CE® and CE.NET® operating systems, for example, or in anInternet and Intranet environment. Rapid Application DevelopmentEnvironment 72 provides a simple drag-and-drop, point-and-clickdevelopment environment enabling the user to mimic complex behavior oflive processes. Such processes may operate in a factory, oilfield,operational environment, or other industries where rich data andgraphical applications are a requirement.

To emphasize the significant operational improvements that the disclosedsubject matter makes possible, the following discussion details selectedaspects of Rapid application Development Environment 72. 72 operating incombination with database communications system 30, a robust set offunctions at both the device and overall system levels emerge.

Rapid Application Development Environment 72 uses real-time, graphicalinterface 70 to develop a variety of applications such as industrialautomation, instrumentation, and embedded systems application programs.From the use of Rapid Application Environment 72, a user may publishreal-time dynamic and animated graphic screens, trends, alarms, reports,and recipes to standard browsers, while allowing data exchange betweenwireless and mobile devices. Alarms may be user-defined set points thatindicate when a machine or process has gone out of normal operatingparameters, or is going out of normal operating parameters. Events maybe the occurrence of a user-defined condition that requires notificationor recording. Recipes include collections of information used to defineprocess or machine parameters for a specific manufacturing operation.Trends may provide the real-time or historical tracking of machine orprocess measurements. Moreover, a viewer may provide a softwareapplication for viewing database information and related operations.

Rapid Application Development Environments 72 may support amulti-dimensional interface in the Web Thin Client environment, as wellas permit creating stand-alone and Web applications from the samedevelopment environment for applications running on Windows NT®, Windows2000®, Windows XP®, and Windows CE®, CE.NET, or on the Web. RapidApplication Development Environment 72 may integrate seamlessly withWindows desktop applications (such as Microsoft® Word® and Excel®),while interfacing with other third-party packages such as Java®, C, C++,and Visual Basic®. Rapid Application Development Environment application72 may support ActiveX® for Web thin clients to allow a user to viewmultiple Web thin client applications from a common Web browser (such asMicrosoft® Internet Explorer® or Netscape®) through theInternet/Intranet and exchange data with a server using a TCP/IPprotocol.

Using Rapid Application Development Environment 72 provides the userwith the ability to provide online configuration, debugging, and remoteapplication management capabilities, including extensive developmentsupport tools such as message register, error codes, event codes,Database Spy®, and LogWin®. Rapid Application Development Environment 72includes a powerful, flexible tags database with boolean, real, string,and array tags, classes, and indirect pointers and provides tools forconfiguring applications in conformance with the FDA 21 CRF Part 11regulation.

An advanced math library including, for example, 100 or more standardfunctions while employing a flexible and easy-to-use scripting languagepermits programming in providing multi-level security for applications,including use over Intranets and Internet may associate with RapidApplication Development Environment 72. Rapid Application DevelopmentEnvironment 72, in the present embodiment, also conforms to industrystandards such as Microsoft DNA®, OPC®, DDE, ODBC®, XML, and ActiveX® toprovide automatic language translation at runtime as well asinternationalization using Unicode language. The robust functionality ofRapid Application Development Environment 72 permits trending functionsfor keeping track of process behavior online or through historicaltrending and sends information across a network for monitoring onscreens or Web browsers.

Rapid Application Development Environment application 72 may distributeinformation throughout the network for easy monitoring on applicationscreens or via Web browsers. In addition, graphics features of RapidApplication Development Environment 72 may permit creating sophisticatedinterfaces with point and click, drag and drop ease. Rapid ApplicationDevelopment Environment application 72 may import graphics from morethan 15 different formats for enhanced and realistic screens andincludes full-featured screen objects and dynamics with customizableobject properties, such as bar graphs, color, resizing, blinking,animation, scale, fill, positioning, rotation, commands, hyperlinks,combo-boxes, and text input/output. The present disclosure includes anobject-oriented environment for simple application development andscreen and object re-usability and that uses an extensive symbol libraryto simplify development as a part of Rapid Application DevelopmentEnvironment 72.

Rapid Application Development Environment 72 provides a sophisticatedalarms management system that allows the user to send alarms to variousutilities such as screen, e-mail, and Web browser, and archive to theprinter. A user may store notes after acknowledgement of alarm(s) using,for example, a free format alarm message and secondary search keys.Rapid Application Development Environment 72 has the ability to archivealarms to a file, printer, or to a database and filters, sorts, or colorsorts alarms for easier visual interpretation. Moreover, RapidApplication Development Environment 72 may filter alarms by categoriesat runtime.

Recipes and reports may also be provided by Rapid ApplicationDevelopment Environment 72 to create flexible, user-defined recipegroups, import and export recipes, reports, and real-time data in XMLformat, as well as publish real-time dynamic and animated graphicscreens, trends, alarms, reports, and recipes to standard Web browsers.Input/output from Rapid application Development Environment 72, whichmay include more than 200 communication drivers that support OPC (server& client) software and various PC Control packages. Rapid ApplicationDevelopment Environment 72 conforms to Microsoft®.NET®, OPC®, DDE,ODBC®, XML, SOAP®, and ActiveX® industry standards, while also providingcontext-sensitive help functions.

As yet a further demonstration of the above functionally, FIG. 5 showsdevelopment environment 74 for the use of Rapid Application DevelopmentEnvironment application 72. Development environment 74 includes titlebar 76 for indicating the active screen or worksheet. Status bar 78provides quick access to actual information, and menu bar 80 includesthe main product options and controls, which the user may easily accessusing the cursor or your keyboard keys. Auxiliary toolbars 82 provideshortcuts to the main commands used in the development environment.Displays building toolbars 84 includes features and tools used to createor edit objects and dynamics in the application screens. Workspace 84provides tree-view control from which the user may access projectworksheets and screens. Database spy window 66 provides a debuggingtool, which the user may use to monitor and force tags and to executefunctions. Output window 90 displays debugging messages, andScreen/Worksheets window 92 provides an area where the user may editscreens and worksheets. Note that FIG. 5 shows the developmentenvironment areas and windows in their default position. The user maycustomize this environment as needed by changing the position of theareas. In particular, the use may right-click the mouse almost anywhereinside the development environment to display a pop-up menu relating tothe context on which the click occurs.

FIG. 6 shows more generally the functional aspects of the gatewayprocess and system 100 of one embodiment of the disclosed subjectmatter, which process occurs using database gateway software 54 atdatabase gateway site 34. In particular, gateway process and system 100permits communication from application site 32, which may operate usingan operating system (OS) that does not support access to databases suchas relational database. As discussed above, applications site 32includes various third party applications 102, such as HMI/SCADAapplication 72. These third party applications 102 may communicate with,for example, a studio ADO® gateway client 104. Communication layer 106provides proprietary, /http:, or /https: protocols for allowingcommunication with database gateway site 34. Database gateway site 34operates, as will be discussed further, an operating system database API108 or set of functions exported through a library which third partyapplications 72, may call to perform database operations. Database API108 interfaces, for example, ADO gateway server 110. With thefunctionality at database gateway site 34, access with relationaldatabase 60 at the local or remote relational database site 40 mayoccur.

FIG. 7 presents an exemplary client-server environment 120 in which topractice aspects of database communications software 54 of the presentdisclosure. In particular, the example shows studio ADO® gateway client104 to include API software 122, which communicates with parser 124.Parser 124 interfaces protocol stack 126, all as components of studioADO® gateway client 104. Through communication path 128, communicationsfrom studio ADO gateway client 104 occur with OS communication API 130.From OS communication API 130, communications occur via path 132 with OScommunications API 134. OS communications API 136 provides thecommunications software for communications with studio ADO® gatewayserver 138 via path 136. Studio ADO® gateway server 138 includesprotocol stack 140, which interfaces OS communications API 138 as aninitial step in communications. From protocol stack 138, communicationssignals occur with parser 140, which further communicates with databaseinterface block 142.

Studio ADO® gateway client API 122 provides a set of functions that maybe exported through a library of third party applications seeking toperform database operations. Parser 124 of studio ADO® gateway client104 and parser 140 of studio ADO® gateway 110 translate requests and/orreplies into commands and format the data to permit OS independentcommunications. Protocol stack 126 of studio ADO® gateway client 104 andprotocol stack 138 of studio ADO® gateway server 110 format dataaccording to the protocol in use and send the information to therespective OS communication API 130 or 134. The OS Communication APIs130 and 134, for example, may be Berkeley Sockets®, WinSock®, SerialCommunication APIs, etc. Database interface block 142 receives therequests from parser 140 and translates the requests into OS DatabaseAPI calls to access particular SQL relational databases.

Parsers 124 and 140 are generic and may interface with any differentrelational databases. Also, each of parser 124 and 140 has the abilityto work with systems that are based on Unicode, as well as ones notbased on Unicode. The present embodiment achieves this feature by alwaystranslating each character from a given application into two bytes inparser 124. On server side 110, parser 140 determines whether theinformation should be used as one or two bytes. Parser 124 on clientside 104 differs from parser 140 on server side 110 in that receivesfunction calls and translates the received data. The information that isdelivered to OS communications API 130 includes the function call andtranslated data. This information is then communicated to OScommunications API 13 and protocol stack 138. In response, parser 140 onserver side 110 simply requests data from the database file 60 andreceives back the information for use ultimately on client side 104.

Protocol stack 126 on client side 104 and protocol stack 138 on serverside 110 provide commands for mimicking the operations that may beperformed at database file 60. Thus, if an application 52 calls todatabase file 60 requesting data, protocol stack 126 translates therequest to code that may be received by protocol stack 138. In so doing,protocol stack 126 adds a header that properly identifies theinformation from parser 124. Then, protocol stack 138 strips the headerfrom the data and prepares the data for its being presented to parser140.

With the present embodiment, passwords may be passed between protocolstack 126 on client side 104 and protocol stack 138 on server side 110.This operation includes encrypting passwords and other data, asappropriate, by protocol stack 126 and decrypting such passwords andother data by protocol stack 138 on server side 110. These operationsmay or may not occur with the knowledge and awareness of the user,according to the overall system configuration and security policies.

FIG. 8 depicts functional aspects of a relational database 60 that maybe accessed using an embodiment of the disclosed subject matter.Relational database 60 may include, for example, Table X 150 and Table Y152. Each such Table 150 and 152 provides the ability to store indifferent registers, e.g., Registers 1, 2, and 3 data in correspondingfields, e.g., Fields A, B, and C. Typically, the fields are pre-definedand the application adds or reads one or more registers, according tothe query condition. SQL relational database 60 may reside within adesktop computer. SQL relational database 60, therefore, provides a setof information stored in tables with fields and registers, which supportSQL commands.

Database communication system 30 of the present disclosure implements ageneric access so, for example, HMI/SCADA application 72 may routerequested remote database operations to a desktop computer runningWindows XP® or Windows 2000®, where it uses ADO.NET® to provide anintuitive, simple, flexible and powerful interface with any databasecompatible with MDAC (Microsoft Data Access Components), usingunderlying technologies such as OLE-DB and ODBC®. Databasecommunications system 30 may interface with any relational databasesupported by a valid ADO.NET® provider, OLE-DB provider, or ODBC®driver. These include, for example, Microsoft SQL Server 2000®,Microsoft Access 2000®, Microsoft Excel 2000®, Oracle®, SybaseAnywhere®, and MySQL®.

FIG. 9 further portrays an application of the disclosed subject matterenabling the access to and communications with a plurality of databasesoperating under a variety of protocols for a variety of applications.Specifically, various alarms, events, trends, and other applications mayfeed from third party applications 72, described above. Referring toFIG. 9, alarms, events, trends functions of a studio application 162 maybe located at one or more remote locations 32 communicate with databasegateway 54. Database gateway 54 may selectively and in a coordinatedmanner, communicate with operating systems of different databaseproviders, such as those from SQL Server® 164, Oracle® 166, OLE-DB® 168and 170, and/or ODBC® drivers 172. In addition, communications may occurusing the Microsoft Jet® OLE-DB provider drivers 174 and 176. Similarly,ODBC® drivers 172 may communicate with OBDC® driver for CSV® file 178.

These applications and relative functions may take place at a singledatabase communications gateway location 34 or at any number ofdifferent locations, depending on the system configuration. Then, afamily of relational databases, including, for example, SQL Server® 180,Oracle® 182, Microsoft® Access (using the *.mdb file format), Excel®,and CSV® file 188. Such databases may be commonly or separately locatedwith one another, as well as commonly or separately located with thedatabase gateway software 52.

In other words, database communications system 30 uses databaseproviders (ADO.NET®) 164 through 172 to interface with databases 180through 188. Database providers 164 through 172 include librariesdeveloped to access data from different databases through SQL commands.The ADO.NET® provider for a specific database may be supplied by theoperating system or by the database manufacturer. FIG. 9 furtherillustrates how database communications system 30 may interface withdifferent databases using a different database provider for eachdatabase 60. Notice in FIG. 9 that the Microsoft ADO.NET® provider forODBC drivers 172 allows the user to access the CSV® file database 188through an ODBC® driver 178. It is also possible that the user may nothave an ADO.NET® provider, but an OLE-DB provider 174 and 176 may beavailable. By using the Microsoft ADO.NET® provider 168 and 170 forOLE-DB, the user may access the respective databases, here MicrosoftAccess® database 184 and Excel® database 186, respectively. MicrosoftJet® OLE-DB providers 174 and 176 give access to applications in theMicrosoft Office® package by using this approach.

It is important to note that database communications system 30 providesthe interface for ADO.NET® providers 164 through 172. However, theADO.NET® providers 164 through 172 and/or the OLE-DB providers 174 and176, and ODBC® driver 178 must be supplied either by the operatingsystem or by the database manufacturer. If a connection string does notrefer to a valid ADO.NET® provider, the disclosed subject matter may usethe OLE.DB provider 174 and 176, for example.

Although most applications typically link to only one type of database,database communications system 30 gives the user the flexibility to linkeach task to a specific database supported by a database provider.Furthermore, by using an architecture similar to that here provided, theuser need have no worries about the specific characteristics of eachdatabase. Such will be mostly handled by the database provider for eachdatabase or by the database gateway software 54. Therefore, theapplication settings are mostly uniform, regardless of the specificdatabase chosen.

Depending on the architecture of a given project employing databasecommunications system 30, ADO.NET® provider 194 for SQL relationaldatabase 180 may not be available in the same stations where RapidApplication Development Environment 72 runs. This scenario is especiallycommon when the application is run on the Windows CE® operating system.At present, most of the providers are not supported for the Windows CE®operating system.

In summary, techniques are here disclosed for communicating between anindustrial apparatus and at least one remote database for a wide varietyof applications, including B2B applications, human machine interface andsupervisory control and data acquisition. This disclosure includes adatabase gateway for enabling communications between a plurality ofapplications and a predetermined database. The plurality of applicationsmay reside on an industrial apparatus not operating database driverinterfaces. A database gateway process and system interfaces between theplurality of applications and at least one driver application forproviding access to a database, such as a relational database. Theplurality of application interfaces access a predetermined database,such as a relational database, by communicating signals with thedatabase gateway. A parser translates the communications signals fromthe application program interfaces into commands and formatted data,which commands and formatted data are operating system independentsignals. A protocol stack formats the operating system independentsignals to form formatted signals, which accord with a predeterminedprotocol and further communicates the formatted communications signalsto at least one database interface. The database interface receives andtranslates the formatted communications signals into database accesscommands for communicating with the predetermined database.

The processing features and functions described herein may beimplemented in various manners. The foregoing description of thepreferred embodiments, therefore, is provided to enable any personskilled in the art to make or use the claimed subject matter. Variousmodifications to these embodiments will be readily apparent to thoseskilled in the art, and the generic principles defined herein may beapplied to other embodiments without the use of the innovative faculty.Thus, the claimed subject matter is not intended to be limited to theembodiments shown herein but is to be accorded the widest scopeconsistent with the principles and novel features disclosed herein.

1. A database communications system for enabling communications betweena plurality of applications and a predetermined database, comprising: anapplication program interface for interfacing with at least oneapplication program, said at least one application program seekingaccess to a predetermined database and operating on an operating systemnot operating a database driver program; a first parser for translatingcommunications with said application program interface into commands andformatted data, said commands and formatted data of a operating systemindependent form; a first protocol stack for formatting said commandsand formatted data into header formatted communications signals, saidheader formatted communications signals formatted to accord with apredetermined protocol, said protocol stack further for communicatingsaid header formatted communications signals; a second protocol stackfor receiving said header formatted communications signals and removingheader data from said header formatted communications signals forgenerating database communications signals; a second parser forreceiving said receiving said database communications signals,generating from said database communications a plurality of databaseformatted SQL commands, and communicating said database formattedcommands; and a database interface for interfacing said predetermineddatabase and communicating said database formatted SQL commands withsaid predetermined database.
 2. The database communications system ofclaim 1, wherein said at least one application program comprises a humanmachine interface application program.
 3. The database communicationssystem of claim 1, wherein said at least one application programcomprises a supervisory control and data acquisition applicationprogram.
 4. The database communications system of claim 1, wherein saiddatabase formatted communications signals comprise open databaseconnectivity formatted communications signals.
 5. The databasecommunications system of claim 1, wherein said database formattedcommunications signals comprise structured query language relationaldatabase formatted communications signals.
 6. The databasecommunications system of claim 1, wherein said database formattedcommunications signals comprise ActiveX® database object formattedcommunications signals.
 7. The database communications system of claim1, wherein said operating system supporting said an application programinterface comprises a Windows CEO operating system.
 8. The databasecommunications system of claim 1, wherein said operating systemsupporting said an application program interface comprises a Linux®operating system.
 9. The database communications system of claim 1,wherein said operating system supporting said an application programinterface embedded operating system.
 10. The database communicationssystem of claim 1, wherein said at least one application programdetermines alarm conditions associated with an industrial apparatus. 11.The database communications system of claim 1, wherein said at least oneapplication program determines events associated with an industrialapparatus.
 12. The database communications system of claim 1, whereinsaid at least one application program determines operational trendsassociated with an industrial apparatus.
 13. The database communicationssystem of claim 1, wherein said at least one application programassociated with recipes for the operation of an industrial apparatus.14. The database communications system of claim 1, wherein said at leastone application program controls operational characteristic viewerfunctions associated with the operation of an industrial apparatus. 15.The database communications system of claim 1, wherein said at least oneapplication program controls web-based functions relating to theoperation of an industrial apparatus.
 16. The database communicationssystem of claim 1, further comprising a wireless communications pathbetween said first protocol stack and said second protocol stack. 17.The database communications system of claim 1, further comprising aTCP/IP communications path between said first protocol stack and saidsecond protocol stack.
 18. A method for communicating between aplurality of applications and a predetermined database, comprising:interfacing with at least one application program seeking access to apredetermined database and operating on an operating system notoperating a database driver program; translating communications withsaid application program interface into commands and formatted data,said SQL commands and formatted data of a operating system independentform; formatting said commands and formatted data into header formattedcommunications signals, said header formatted communications signalsformatted to accord with a predetermined protocol and communicating saidheader formatted communications signals; receiving said header formattedcommunications signals and removing header data from said headerformatted communications signals for generating database communicationssignals; receiving said receiving said database communications signals,generating from said database communications a plurality of databaseformatted communications signals, and communicating said databaseformatted communications signals; and interfacing said predetermineddatabase and communicating said database formatted communicationssignals with said predetermined database.
 19. The communications methodof claim 18, wherein step of interfacing said at least one applicationprogram further comprises the step of interfacing a human machineinterface application program.
 20. The communications method of claim18, wherein step of interfacing said at least one application programfurther comprises the step of interfacing a supervisory control and dataacquisition application program. 21-37. (canceled)